Grupo 11 - PawTel

Universidad de Sevilla
Escuela Técnia Superior de Ingeniería Informática
Ingeniería de Software y Práctica Profesional (ISPP)
Curso 2024-25

Equipo:

• Andrés Martínez Reviriego
• Claudio Cortés Carrasco
• Daniel Flores De Francisco
• David González Martínez
• Fernando Castelló Sánchez
• Francisco Miguel Jiménez Morales
• Javier García Sebastián
• Javier Ruiz Garrido
• Jorge Gómez de Tovar
• Luis Mellado Díaz
• Manuel Castillejo Vela
• Rafael Castillo Cebolla
• Sergio Trenado González
• Yesica Garate Fuentes

---

Introducción

En esta página se encuentra el feedback recogido por el equipo del grupo 11 durante las sesiones de clase. Haciendo uso de una división semanal, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana.

Semana 1

Fecha: 07/02/2025

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	- Número de grupo visible. - Incluir el logo del proyecto en las diapositivas. - La plantilla debe transmitir algún valor (ejemplo: espacio de publicidad gratuita). - Incluir un manual de identidad corporativa. - Mejorar la legibilidad y la consistencia en la fuente de letra. - Apagar la presentación cuando se quiere captar la atención del público directamente. - No hablar rápido ni competir con textos largos en pantalla. - Evitar usar la presentación como guía; mejor tener un papel en la mano.	- Incluir mockups o elementos visuales cuando ayuden a la comprensión. - Presentar el análisis de competencias en forma de tabla. - Definir claramente si el público objetivo es un conjunto o subconjuntos disjuntos. - En el modelo freemium, todos los usuarios deben considerarse clientes potenciales. - No mezclar equipos con roles en la presentación.
Grupo 8 - Friends on Tour	- Logo con letras y nombre. - Mejor poquito y bueno que mucho y mediocre en el MVP. - Modelo de negocio basado en comisión a terceros. - Explicar claramente las protopersonas.	- Hablar de la competencia antes de las amenazas.
Grupo 9 - Empollapp	- Unir la value proposition con el participante en el business model canvas. - Logo y nombre que reflejen la utilidad de la app. - Orden de los puntos por importancia. - Exponer problema y solución antes de la monetización.	- Incluir solo la información relevante, evitar contenido innecesario. - Ser estrictos con quienes no contribuyen al trabajo.
Grupo 10 - Appagar	- Índice legible y claramente ordenado. - No seccionar demasiado el índice. - Evitar explicar cosas obvias o innecesarias.	- No hacer una sección de preguntas y respuestas; responder en las diapositivas de manera natural.
Grupo 11 - MeetUs	- No podemos ser nuestros propios clientes. - Justificar por qué los clientes pagarían. - Reconsiderar la idea.	- Decir lo que se ha hecho, aunque no esté en la presentación.

Lista de tareas para la próxima semana

• Poner la base de conocimiento en común con el resto de grupos. Los profesores deben tener acceso. Ver DocuSaurus.
• Leer model business canvas libro de negocio. SEMANA 2 - IDEA DE NEGOCIO
• Key business idea clarisima, de que va y de que no va
• Analisis de competidores preliminar muy riguroso, todos los competidores (si el profe encuentra otro nos one shotea)
• Criterio de busqueda, como llegaste a la conclusion de que esos son los competidores. Tabla objetiva, nada de sesgo.
• Análisis de coste TCO
• Usuarios pilotos potenciales, pensar en la diversidad y planes de precio, cobertura de casos, población heterogenea
• Como vamos a trabajar con los usuarios piloto, como guardar su info y como tratarla.
• Prototipos de baja fidelidad MVP
• Casos de uso core -> mockups con interacciones importantes -> balsamic y otros prototipos de media alta fidelidad
• Discusion de la tecnologia EQUIPO
• Uso de ia
• Commitment
• Analis de riesgo preliminar -> PMBOK -> negocio + ejecucion
• Equipos y roles bien definidos
• Habilidades del equipo

---

Semana 2

Fecha: 14/02/2025

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	- No hacer referencias a presentaciones de semanas anteriores o a presentaciones de otros grupos. - Seguir buscando competidores, no vaya a ser que la caguemos. Preguntar a ChatGPT. Le damos la idea del negocio y que nos busque competidores. - Explicar por qué primero presentamos muchos competidores y luego nos centramos en unos pocos. ¿Por qué nos centramos en eso? ¿Son más parecidos? - Primero explicar las funcionalidades claramente y ya luego del sistema de negocio y costes. No hablemos del dinero hasta que no tengamos interés por pagar. - En el Business Model Canvas, no incluir cosas irrelevantes. Si los estudiantes no proponen un caso de uso distintivo, no lo ponemos. - Pensar incluir anuncios. - Agrupar funcionalidades similares en módulos al hacer comparaciones. - Ordenar comparaciones por casos de uso. - La publicidad debe estar en la parte superior y las conexiones deben ser claras. - Especificar explícitamente qué servicios son gratuitos y cuáles son de pago.	- En amenazas de la DAFO, dependencia de APIs de terceros. - Leer y hacer Business Model Canvas. - Han mostrado todas las funcionalidades junto a su mockup. Pensar si nos puede ser útil. - Triángulo de innovación de servicio, tecnología y negocio.
Grupo 8 - Nutribaby	- En mockups no poner lorem ipsums ni nada. ¡Poner textos realistas! - Tener en cuenta los costes sociales en sueldos y horas de trabajo. - Página para ver sueldos de perfiles en España: getmanfred.com, Tech Career Report. - Competidores después de las funcionalidades. No poner los costes en medio. - Hablar de la privacidad (aunque en nuestro caso sea el pago), como un riesgo. - Asegurar coherencia en el mensaje de la presentación.	- Comienzo fuerte. - Han puesto una foto de un móvil con varias aplicaiones en el escritorio y una de ellas es Nutribaby. Muy eficaz para demostrar potencial como aplicación real. Ya lo hicieron la otra vez y quedó muy bien. - Todo muy grande para que se viera bien, aunque a lo mejor han apurado demasiado los espacios. - Mucho texto. - Han hecho un cálculo de los costes y los presupuestos del proyecto.
Grupo 9 - Caronte	- Innovar. Salirse de las convenciones. Personalizar a generaciones futuras. Pensar cosas que tradicionalmente no se ven bien, pero no están justificados, y darles la vuelta. Ser disruptivos para captar la atención del cliente. - Transformar la idea de pasiva a activa, buscar cómo atraer a los usuarios. - Los UMLs se sienten demasiado formales y poco claros. Son técnicos pero no para ponerlos en una presentación. - Cuidado con que el Business Model Canvas sea demasiado chico y no se vea bien. - Generar hype con la presentación. - Alternar presentadores no siempre mejora la presentación, valorar hacerlo con un solo expositor. - No desacreditar a la competencia, sino resaltar diferencias estratégicas.	- Estrategias de publicidad. - Han hecho el Business Model Canvas (1 Ley parnerships, 2.1 Key activities, 2.2 Key rsources, 3 Value propositions, 4.1 Customer relationships, 4.2 Channels, 5 Customer segments, 6 Cost structure, 7 Revenue stream) - Han dado datos como el número de funerarias, el número de muertes anuales y demás. - Tecnologías preferidad de cada miembro. Habilidades: programación, business y soft skills.
Grupo 10 - Go4Surprise	- Gastos altísimos y probabilidad de beneficios muy bajas. - Demasiadas elecciones para el cliente. A veces la decisión genera estrés. - Mock ups que cuenten una historia. Que no sean ventanas random. Aquí la ventana del login, aquí la ventana de otra cosa... - Usar el espacio de pantalla eficientemente en los mock-ups. - Los iconos de las aplicaciones que no estén sueltos en la diapositiva. Que se explique para qué se va a usar cada una. Diagramas de arquitectura. No poner logos innecesarios, que no es publicidad. - Que el logo de la aplicación no esté en la parte superior izquierda. - Ir marcando las secciones para que la gente no se duerma. Con los números de las secciones, con las páginas (actual/total) - Considerar el hardware y amortización de costos. - Detallar el Commitment Agreement y un plan de cumplimiento semanal. - Incluir métricas como TFO (Tiempo de Funcionamiento Operativo) por mes. - Incluir costos de operación en GitHub y usar HBS (Hora Básica de Servicio) para estimaciones.	- Han hablado de los gastos de despliegue.
Grupo 11 - Pawtel	- Invertir más tiempo en qué somos que en qué no somos. Demasiadas preguntas sin respuestas. Demasiado mensajes negativos. Demasiado tiempo diciendo qué no somos. - Dejar un poco más claros los conceptos. No usar términos ambiguos. ¿Qué significa hotel para mascotas? Dice que usemos Residencia para mascotas mejor, pero ya veremos. Aclarar qué somos y diferenciarnos de hoteles "pet-friendly". - No hablar del posicionamiento muy temprano. Primero vamos a dejar claro de qué va la aplicación, y ya luego empezamos a comparar con otras - Reducir el "ruido" con respecto a la competencia. No queda claro muchas cosas. Durante esta parte seguimos hablando de lo que somos y no somos, como si no lo hubiéramos dejado claro. Y tenemos muchas diapositivas de competencia que saltan de un lado para otro, y queda un poco lioso. - Darle importancia a todas las cosas, que ha sido demasiado larga la presentación y hemos ido corriendo por algunas diapositivas. Lo que no vayamos a comentar no merece estar en la presentación. - Asegurar legibilidad y coherencia en las diapositivas. - Más grande los riesgos, que no se leen. - La presentación debe ser comprensible sin necesidad de visualizar las diapositivas. - No poner todos los riesgos si no los vamos a leer. Entonces no haría falta ponerlos todos. No hay que volcar documentación por volcarla. - Tipo de letra en soft skills no es buena. No decir que el gráfico está volcado para la derecha si no aporta nada. Si acaso, leyenda. Igual con las otras gráficas. - ¿Hacer la aplicación de pago? Porque no vaya a ser que no compren por ahí y al final no ganemos dinero. - Explicar cómo funcionará la monetización si no hay pasarela de pago en el MVP. - Relativizar los valores de mercado. ¿Es 10% más barato que lo que cobra Booking? ¿Es la ganancia inferior al 25% del mercado? - Ponemos strikes, sí, vale, pero hay que explicar qué significa un strike. ¿Un día sin trabajar? ¿Fuera del equipo? El objetivo es mejorar el ambiente de trabajo. El sistema de penalizaciones es el medio para alcanzar el objetivo. - Igual que hemos hecho con las softskills, hacedlo con las hardskills. Incluir habilidades tecnológicas del equipo y costos de aprendizaje de nuevas tecnologías. - Justificar reparto de equipo en grupos. - Aclarar que todos los miembros del equiupo pueden pertenecer a varios equipos, pero que todos los miembros del equipo desarrollan. - ¿Por qué hemos decidido las tecnlogías de backend y frontend? ¿Por qué si no las conocemos? Explicar. - Todo lo mostrado tiene que estar justificado, tanto en pantalla como por el presentador. Hay que soltar factos y datos concretos. - Nos falta sección de innovación. Poner junto/tras competidores. - Competidores: Si tienen el mismo modelo de negocio pero nada que ver con mascotas de este estilo, no son competidores. Seleccionar los más importantes. - Crear un Business Model Canvas.	- No sustituir palabras por imágenes. Mejor poner "Gratis para usuarios" que una foto que ponga "Gratis" y luego el título sea "Para usuarios". - Comentar que puedes buscar hotel para tu mascota en la ciudad a donde vayas, y poder llevártelo contigo. - En costes y tecnologías, el logo se ha salido fuera de pantalla. - Estudiar el porcentaje de comisión.
General	- Orden de presentación: el producto que desarrollamos. La venta se hace "sola" si el problema que resolvemos está claro y es atractivo. - Menciones honoríficas de la semana y Hall of shame de la semana. - Alinear los riesgos con lo que hayamos hablado antes, principalmente la DAFO. Comentarlo o indicarlo visualmente. - Los riesgos no se definen por nada, sino para evitarlos. - Tener unidades homógeneas para los datos. - Las presentaciones deben ser autocontenidas, evitando referencias a presentaciones anteriores, nuestras o de otros equipos.

Lista de tareas para la próxima semana

Tiempos y test

• 16 min. de presentación. 13 min. de feedback.
• Test depués. Traer ordenador cargado.

PMBOK

• Planes para cada fase
• Planes de calidad
• Definir cuándo hacemos seguimiento y control
• Plan de gestión de riesgos, incluyendo teoría y acciones concretas.

Elevator pitch (inicio efectivo)

• Claro todo desde el principio, sin ambiguedades, en 10 segundos, todo claro. Inicio efectivo.

Costes

• Coste de personal
• Coste de amortización
• Costes indirectos
• Costes de herramientas y licencias
• ...
• Análisis preliminar de costos (TCO, amortización de activos, personal, licencias, etc.).

Usuarios pilotos

• Definir súper bien TODO del programa de usuarios pilotos.
• Recolección de datos homogénea.

MVP

• Aclarar casos de uso clave.
• Mockups que muestren interacciones, que cuenten una historia. O que sean interactuables.
• Tener en cuenta UX no solo UI para los mockups. Echar un vistazo a lawsofux.com .

Tecnología

• GitHub, GitHub Actions y GitHub Projects.
• Desplegar donde queramos, pero todos los despliegues tienen que ser auditables a futuro, es decir que tenemos que guardar todas las versiones de los despliegues (al menos 1 por semana) y que después se pueda acceder a cada una de ellas, no solo a la última.
• Justificación del stack tecnológico, visualización del conocimiento del equipo.

Página web para la startup

• Branding page.
• Correo de contacto al final.
• Landing page con idea principal y contacto.

Planificación sprints

• Planificación MUY detallada del sprint 1 (siguiente semana). Roles y responsabilidades. Dónde estamos y dónde queremos acabar.
• Planificación ligera de los dos sprints posteriores (2 y 3).
• Hacer esto todas las semanas. Planificamos en detalle el siguiente sprint y planificamos ligeramente un sprint más.

Doc IA

• Uso estratégico de la IA en el desarrollo del proyecto.

Semana 3

Fecha: 21/02/2025

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	- Se ha mezclado el commitment agreement del stack. Fallo menor - En general la presentación ha sido buena. - Solo van a usar WebSocket, es poco común. gRPC como alternativa a WebSocket. - Pequeño ajuste en el modelo de negocio pero generalmente bien. - PMBOK no es una metodología, es un marco de referencia. - Despliegues fijos. Tienen que ser accesibles de primer momento. - Han hablado sobre la gestión de conocimiento con sólo una diapositiva, pero renta más utilizar varias para no dar sensación de estancamiento.	- Leer y hacer Business Model Canvas. - Han mostrado todas las funcionalidades junto a su mockup. Pensar si nos puede ser útil. - Triángulo de innovación de servicio, tecnología y negocio.
Grupo 8 - Nutribaby	- No se salta al MVP, hay que explicar el producto en su totalidad y luego podar funcionalidades. - MVP demasiado amplio. - No han explicado cual es cada competidor, ni qué hacen, ni cómo los han encontrado. - Justo después de competidores saltan a los riesgos (producto -> competidores -> MVP -> recursos -> riesgos es buena idea). - Los números no sirven para nada. Más útil las palabras - Beneficio es igual a ingresos menos costes. Han asumido el IVA? Y los planes de coste? Poca legibilidad - Han elegido una mala estructura. - No tienen la planificación de los sprint. - Faltan cosas en la presentación. Intentar que el trabajo que se ha hecho durante la semana esté bien reflejado en la presentación. - Mala tipografía para el cuerpo. - No han hablado de en qué consiste el premium antes de hablar de los costes y beneficios.
Grupo 9 - Caronte	- Ha hecho referenciado los mismos competidores. - Se han quedado sin tiempo. - Nube de competidores que no aporta nada a la presentación. Tienes que indicar porqué has descartado los competidores y explicar los competidores. - Las protopersonas no dan feedback. No digas que dan feedback - Business Model Canvas no se lee, letra muy chica. - Usar tecnologías que nos habiliten desarrollo multiplataforma. - El cambio entre vídeo y diapositivas queda mal. - Business model canvas tiene flechas que lo cruzan, debería ser más transitorio. - Fotos deberían ser homogéneas.	- Ninguna observación adicional.
Grupo 10 - Go4Surprise	- No minimizan el riesgo sobre la cancelación, el plan de contingencia es malo. - Es verdaderamente rentable? De donde salen los datos de ingreso y rentabilidad. - Números de diapositivas más grandes. - Qué es optimizar el algoritmo? Eso no tiene sentido - El MVP va bastante tarde, al final de la presentación. Hay que ponerle cara al proyecto lo antes posible. - Hilar la presentación, no usar índices excesivos. - La barra de progreso no se nota. - Indicar unidad temporal de costes, y tener en cuenta costes sociales. - Tener en cuenta la escala geográfica en la que se trabaja.	- Fotos no uniformes. - No dicen de donde sacan salarios.
Grupo 11 - Pawtel	- Abrir a todo tipo de mascotas y no animales. Si hacer algo no supone un incremento de trabajo a nivel técnico, es buena idea hacerlo. - Poner caso realista frente al optimista y pesimista. - Distinguir navegador, donde se ejecuta. - Tabla de competidores se ve mal. - Menos texto en las diapositivas. - En diagrama, poner flechas dobles, y usar imagotipo en vez de logotipo. - Tema de imágenes unificarlo. - La falta de planificación no es un riesgo.
General	- Orden de presentación: el producto que desarrollamos. La venta se hace "sola" si el problema que resolvemos está claro y es atractivo. - Menciones honoríficas de la semana y Hall of shame de la semana. - Alinear los riesgos con lo que hayamos hablado antes, principalmente la DAFO. Comentarlo o indicarlo visualmente. - Los riesgos no se definen por nada, sino para evitarlos. - Tener unidades homogéneas para los datos. - Las presentaciones deben ser autocontenidas, evitando referencias a presentaciones anteriores, nuestras o de otros equipos.

Para hacer pero no necesariamente para la presentación

• Métricas cuantitativas para seguir el rendimiento. Sacar números para saber cómo van las cosas. De GitHub por ejemplo. Cuidado con las normas basadas en estas métricas, por si la gente infla el número de commits con tonterías.

Para la presentación

• Killer opener, business model, transmitir la idea y crear hype. ' Analisis de costes.
• Competidores.
• Equipo (con menos importancia).
• Cumplimiento del commitment agreement.
• Roles de cada uno en este primer sprint y cómo han afectado al proyecto, en qué han trabajado.
• seguimiento del commitment agreement, cómo se han portado.
• Cuando mostremos la aplicación ya va a ser software. No hace falta que lo mostremos en directo, sino que pueden ser capturas de pantalla.
• Retrospectiva de mitad de sprint. Análisis del rendimiento (con las métricas establecidas), cuánto hemos trabajdo, finalización de tareas, problemas, lecciones aprendidas, propuestas de resolución. Horas estimadas vs las reales. En qué parte del proyecto estamos. Hablar sobre discrepancias con planificación temporal (Reloj de avance del proyecto)
• Cómo solucionamos los problemas al final. Se espera que sigamos las contingencias del plan de riesgos. Si no, está bien cambiar y adaptar, pero comentarlo y actualizar los riesgos.
• Está perfectamente bien cambiar el plan. Pero comentarlo.
• Seguimiento y Control de como vamos en el proyecto.
• Gestión de usuarios pilotos (MUY IMPORTANTE). Más detalle ya. Cómo vamos a comunicarnos, cómo se lo vamos a dar. Hablar de la agenda. Cómo vamos a tomar el feedback.
• Report de como hemos usado la IA.

Estimación de tiempos de presentación

• 15 min de presentación a partir de ahora.
• Unos 6 o 7 minutos para estas cosas nuevas de evaluación de rendimiento, retrospectiva y tal.
• Reducir previas partes:
  • Killer opener y elevator al grano
  • Equipo, reducir mucho
  • Reducir competidores (no significa ponerlo y pasar para adelante)

Adicional

• Arreglar lo del patrocinador en los documentos.
• Estudiar competidores cada semana (si no cambia, perfecto; si sí, pues cambiar). Si tenemos definido un proceso concreto para sacarlos, repetirlo.

Semana 5

Fecha: 07/02/2025

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	- Poner el porcentaje de avance en la parte de avance del proyecto.	- Los precios no están muy claros, mejor en una tabla. No usar llaves, quitan espacio. - Usar términos aprendidos en otras asignaturas (PSG2). - Los números de las páginas deben verse bien. - No mezclar español e inglés. - Enfocar la parte de problemas en Problema -> Solución (con todo lo que conlleva).
Grupo 8 - Nutribaby	-	- Buscar usuarios piloto útiles, los usuarios piloto locales no son padres. - Si falta algo en una presentación y en la siguiente no hay que ponerlo, no se pone aunque no lo hayas puesto antes. No "recuperar" cosas. - Ordenar la información para transmitir lo más importante. - No poner diagramas completos o similares porque no se ven bien. Se pueden resumir con las cosas más importantes. - No poner muchas siglas ni mencionar siglas sin explicación.
Grupo 9 - Caronte	- Costes PERT. - Bien usado el burn-up chart de issues abiertas y cerradas. - Costes demasiado bajos, hay que añadir el mantenimiento, servicio al cliente, etc.	- Tener en cuenta el soporte post-lanzamiento y los servidores. - No dar por sentado que la gente va a empezar a usar la app desde el principio. - No trabajar con IVA. - Encontrar más usuarios pilotos. Que cada uno se traiga dos o tres. - Caso interesante: baja por enfermedad. No se puede dar el caso de "como te has puesto malo, ahora te pongo a trabajar más". - Hay que contar qué hacemos antes de hablar de la competencia.
Grupo 10 - Go4Surprise	- La estructura de la presentación no la han cumplido. - No han hecho inicio efectivo. Es algo fundamental y que tiene que estar en todas las presentaciones. - Intentar hacer la parte de costes liviana, debe ocupar más o menos un 20% de la presentación, 3 min, y en ese tiempo no da para contarlo todo. - Tenían que haber abandonado algunas cosas de las semanas anteriores que ya no son tan relevantes. Quedarnos ya con el core de cada parte. - Quitarle el miedo a los inversores; que quede claro que hay idea Y negocio. - No hablar ya de que tenemos planeado usar usuarios pilotos, sino hablar directamente de cómo lo estamos haciendo, ya es algo actual. - No hablar ya de la planificación de riesgos sino hablar directamente de qué riesgos hemos encontrado (y podemos mencionar si estaba previsto). - Cuando hablamos del desarrollo no hace falta hablar de cosas nimias como el inicio de sesión a no ser que sea algo particular e interesante.	- Costes fijos y costes variables. - Sprint retrospective: qué ha ido bien, qué ha ido mal, cómo mejorar. - Que el orden de las diapositivas tenga sentido. - Que la demo se vea bien de lejos; si tenemos una fuente pequeña en la página y enseñamos eso mismo, no se verá bien.
Grupo 11 - Pawtel	- Incluido todo lo que nos pidieron. - Número de páginas más visible, porque con ese color no se veía. - Aclarar un poco a qué nos referimos con "Servicios extra" en el análisis de competidores, queda un poco ambiguo. - No nos piden tanto que les contemos todo lo que hayamos hecho, sino los puntos clave, los problemas más importantes y cómo los hemos solucionado. - No solo decir qué tareas hemos completado, sino hablar del porcentaje y relativizarlo un poco. Soporte visual gráfico. - Reducir "estrés" visual con detalles innecesarios en la pantalla. - Mejorar medición de rendimiento para que de verdad refleje la calidad y también porque según el rol es diferente. Podemos hablar de desviaciones puntuales respecto a lo planificado que resten nota y otras métricas para compensar estas pérdidas. No usar solo números, sino también franjas. Poner performance individualmente, aunque también podemos hacer un resumen por grupos. Hasta podemos poner las ponderaciones de las métricas. Pero buen trabajo. - Poner caras en los Halls. - Buen inicio efectivo. Bien sacando cifras. - El del BMC está bien tirado, pero la ejecución no está muy clara, se ve un poco desorganizada y poco fina. - El login parece un pelín demasiado un mockup. - Contar de forma más amena las pantallas. Que no parezca una tras otra como un mockup, de "aquí tenemos, aquí tenemos...", sino que cuenten una historia. - Una agenda más concreta de los usuarios pilotos. - No usar anglicismos como "settear". Viva España. - La casa del logo de Pawtel no se sabe si es una A o una O.	- Creo que las cosas en la diapositiva del BMC están un poco pequeñas y poco claras. Las imágenes de la izquierda no se entienden fácilmente. - En seguimiento del Commitment Agreement hay una palabra con tilde incorrecta (detallito). - En gestión de riesgos y plan de contingencias 1, hay una palabra cortada, una parte en una línea y otra en otra.
General	- El documento "Informe de tiempo y esfuerzo" debe tener gráficas preferiblemente o incluso tablas. Más digeribles. - El documento de report debe contener lo mismo que la base de conocimiento, no enlaces a ella. - Base de conocimiento muy pobre. - Equilibrar trabajo entre miembros del equipo. - Documentación en formato markdown, no en PDF (perrada). - La semana que viene entregar documento Revisión del software. Manual de usuarios explicando lo que está entregado y lo que no, pero enfocado a que los profesores puedan revisarlo. - Mirar la EV cada dos por tres por si han actualizado algo, porque dicen que no van a avisar...

Para hacer pero no necesariamente para la presentación

• Métricas cuantitativas para seguir el rendimiento. Sacar números para saber cómo van las cosas. De GitHub por ejemplo. Cuidado con las normas basadas en estas métricas, por si la gente infla el número de commits con tonterías.

Para la presentación

Estructura principal

15 min (siempre ya)

• Introducción: 15-20% (2-3 min)
  • Killer opener y elevator pitch
  • Análisis de competidores (rápido). Por qué nos distinguimos.
  • TCO: capex, opex, etc. Mejorar cómo transmitimos los números
  • Estimaciones de ingresos y gastos a corto y medio plazo. Importante factor tiempo. Por ejemplo: gráfica bonita de para cada semana, hacia arriba los beneficios y hacia abajo los costes. Y luego una línea de tendencia negativa, positiva y media.
  • Equipo (rápido). Menos importancia a las tecnologías de cada uno (hemos hecho bien).
• Demo resultado sprint 1: 15% (2 min) en directo, pero tener un vídeo grabado por si las moscas. Cuando hagamos la entrega pasamos el enlace, no el vídeo entero.
• Retrospectiva: 40-50%
  • Igual que hoy, pero aplicando el feedback, y hasta el último día.
• Gestión de usuarios pilotos: 10%
  • Conclusiones.
  • Plan para el sprint 2.
• Planificación sprint 2 concreta: 15%
  • Asignación de responsabilidades
  • Objetivos a mitad y final de sprint.
  • Estimación global del resto
• Informe uso de IA.
• Landing page.

Otros

• Mantenemos el guión a rasgos generales y vamos reduciendo partes y dando más importancia a lo nuevo.
• No poner demasiada información, eso hace que el presentador tenga que hablar muy rápido.
• Landing page poner URL, no solo QR.
• Que no falte el informe de uso de la IA.
• Killer opener
• garrreynolds.com -> Página web con tips para presentaciones.

Adicional

• Examen en cualquier momento de la clase.
• ¿Usar codeshare la próxima vez para el feedback?

Semana 6

Fecha: 15/03/2025

---

---

Desarrollo

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	- Poner los enlaces al final. - Añadir problemas encontrados no pensados previamente en registro de riesgos. - Si alguien no puede trabajar no decir "por motivos varios", se puede decir "por motivos personales de distinta índole". Mejor dejarlo cerrado que abierto. - No dividir una tabla en dos diapositivas y explicar mucho de una parte y pasar de largo la otra. Intentar poner/mencionar las cosas más importantes. - Decir cómo influyen las métricas de productividad en la evaluación individual. - Explicar planificación con un Diagrama de Gantt. Si se usan distintos colores, explicar qué significa cada uno.	- En el uso de la IA, es positivo dar detalles sobre usos reales. - Buena gráfica de costes e ingresos.
Grupo 8 - Infantem	- El killer opener ha sido demasiado neutro, hay que atraer más la atención de la audiencia. - Buscar tener el mismo impacto en menos tiempo. - Buen formato de presentación, pero no sobrecargar de muñecos, que los que se usen tengan sentido. - En la parte de competidores, poner las X rojas aunque no siga la línea de colores de la presentación. - Seguir la base de conocimiento. Utilizar elementos realistas en la demo. Si usas datos reales como para el usuario por ejemplo, humanizas la experiencia. - Estructura de roles demasiado piramidal, aunque si es la que funciona usarla y analizar resultados. - Usar herramientas para medir la calidad del código. - Pocos usuarios piloto (solo tienen los de clase). - Analizar cuántas veces "alucina" la IA.	- Buena gestión del feedback de los usuarios piloto. - Buenas diapositivas de MVP y de estimaciones vs realidad.
Grupo 9 - Caronte	- Poner el porcentaje del punto de la presentación no es común ponerlo, y resulta confuso. - Hay que poner el beneficio acumulado, no poner solo los datos mensuales. - En la parte de equipo decir solo eso, equipos, integrantes y poco más, no comentar sobre eso otras cosas como problemas. - Poner las cosas chicas es un recurso visual, se puede poner si lo que quieres transmitir es el volumen, en el caso del equipo enseñar el tamaño del equipo entero. - En horas por persona, se puede mencionar también horas esperadas... dar más información. Si se esperan 30h, se puede poner una línea ahí para ver quién las ha cumplido y quién no. No poner horas totales, no aportan. Se puede añadir una línea con la media también. - Hacer plan de aprobación de la calidad. - Aquello sobre lo que hay mayor incertidumbre tecnológica hay que hacerlo lo primero.	- Buenos gráficos de tareas realizadas y de monetización. - Documento de la IA muy completo.
Grupo 10 - Go4Surprise	- No hacer preguntas retóricas en el killer opener asumiendo que la respuesta en todas es sí. - No hablar de estimación media, sino de estimación esperada. - No poner en la demo el registro + el login, enseñar lo importante, no hace falta enseñar todo. - Mal orden en la sección de retrospectiva, y demasiada letra. Que se pueda ver qué ha ido bien y mal echando solo un vistazo. - Pseudo-diagramas de Gantt: buenos para ver la distribución de tareas y su paralelización, pero para ver todo lo que se ha hecho, malo por su longitud. - Gestión de usuarios piloto: falta información sobre cómo se ha usado el feedback que han dado.	- Buenas gráficas en las diapositivas de ingresos/costes (barras verticales usando valores negativos también), aunque les falta explicación.
Grupo 11 - Pawtel	- Tener cuidado con la instancia con la que desplegamos en Render. - Killer opener -> Poco atrayente, intentar algo un poco más imaginativo, que llame más la atención. - No poner años incompletos en gráficas (se puede poner la media con un asterisco por ejemplo). - Costes: En 24 meses los costes no van a ser constantes, cuando se lanza la aplicación se añaden los de soporte, de service desk, de mantenimiento... - Coste Total Inicial => Coste del MVP, usar terminología clara. - No usar colores en gráficas porque "hay muchos daltónicos". Que lo que se quiere representar no dependa de los colores únicamente. - Poner justificaciones de las estimaciones (pesimista, realista, optimista). Poner en porcentajes cuántos entran en la web, cuántos buscan y cuántos reservan. - Tener cuidado con el modelo de negocio de anuncios. - DEMO -> No se veía bien, hacerlo con zoom. - No solo poner la solución aplicada a un problema, sino el porcentaje en el que esa solución sirve o no.	- Como grupo, hablar de la interfaz con la que se van a comunicar backend-frontend. - Sugerencia: Mejorar sistema CI/CD.
General	-	- Salario = activo (inversión). - I+D y formación son inversiones. - Gastos de personal: Si es gente que participa en un producto = personal, activo, mientras que si es gente que participa en tareas pero no forman parte del producto = operativos. - Cuidado con el coste de los despliegues, que no se nos vaya la mano. Hay funcionalidades que si no están bien hechas se pueden comer el saldo. - Falta en general la automatización de la calidad del código (con aplicaciones como por ejemplo Sonar). Métricas, cómo funciona el sistema... - Informe de IA: Poner ejemplos reales. - Hacer un uso inteligente de la tecnología: Lo hacemos como sabemos, pero existen herramientas y métodos para hacerlo más rápido -> jkipster, postgre, auth0 (para el login). - Podríamos añadir login social (login con Google, Facebook...). - Le gusta cloud porque lo puede transformar en acciones.

Para hacer pero no necesariamente para la presentación

Para la presentación

Estructura principal

15 min (siempre ya)

• Introducción: 15-20% (2-3 min)
  • Killer opener y elevator pitch
  • Análisis de competidores (rápido). Por qué nos distinguimos.
  • TCO: capex, opex, etc. Mejorar cómo transmitimos los números
  • Estimaciones de ingresos y gastos a corto y medio plazo. Importante factor tiempo. Por ejemplo: gráfica bonita de para cada semana, hacia arriba los beneficios y hacia abajo los costes. Y luego una línea de tendencia negativa, positiva y media.
  • Equipo (rápido). Menos importancia a las tecnologías de cada uno (hemos hecho bien).
• Demo resultado sprint X: 15% (2 min) en directo, pero tener un vídeo grabado por si las moscas. Cuando hagamos la entrega pasamos el enlace, no el vídeo entero.
• Retrospectiva: 40-50%
  • Igual que hoy, pero aplicando el feedback, y hasta el último día.
• Gestión de usuarios pilotos: 10%
  • Conclusiones.
  • Plan para el sprint Y.
• Planificación sprint Y concreta: 15%
  • Asignación de responsabilidades
  • Objetivos a mitad y final de sprint.
  • Estimación global del resto
• Informe uso de IA.
• Landing page.

Esto fue para el Sprint 1. En comparación con esto, para la próxima semana:

• Parte inicial, modelo de negocio:
  • De lo anterior sigue existiendo lo mismo.
  • Presentación mas de impacto/marketing. Para cada tipo de usuario/cliente/inversor, debe haber un storyboard, algo que nos permita enseñar de que forma vamos a llegar a esta audiencia. Diseñar que queréis luego grabar. (STORYBOARD = guión de forma visual de cual es la historia que vamos a contar para ese tipo de usuario/cliente/inversor.)
  • Impacto legal del proyecto. RGPD, customer agreement. Considerar si debemos tener un mánager legal de protección de datos para costes.
• Gastos =
• Actualizar OPEX/CAPEX con la parte legal y la parte de los storyboard.
• Equipo =
• DEMO prototipo: centrarnos en el incremento del desarrollo, que hay nuevo. SIEMPRE CON DATOS REALES.
• Retrospectiva: Lo de siempre + Análisis de la calidad
• Usuarios piloto =
• Objetivos final de sprint: tiene que incluir pagos reales con cuentas sandbox. CLAVE
• Se supone que cada vez debe haber menos problemas.

Otros

• Actualizar base de conocimiento común.
• Incluir enlaces que demuestren evidencias.
• changelog se puede generar de manera automática a partir de los commits, igual que con los issues.

Semana 7

Fecha: 22/03/2025

---

Desarrollo

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	- Falta energía en la presentación, algo que termine de enganchar a la gente. - Mal descrito el perfil de usuario al que le interesa la aplicación. "Para gente a la que le guste completar mapa". - Mala tabla para los modelos de negocio. Hay que leer todo para entenderlo y es demasiado. Se puede hacer agrupando por grupos y poniendo logos -> Metáforas visuales. - Centrarse en ir a por un tipo de empresa concreto en el storyboard de empresas, y en el de usuario usar datos reales, sino no convence para invertir. - Seguir usando el mismo ejemplo que usas para el killer opener para el resto de presentación (storyboard, demo...). - Equipo: Poner fotos de los miembros del equipo. - Medir solución, poner objetivo. Además lo han puesto como riesgo, pero son problemas. - DEMO: Han hecho login dos veces. Transiciones demasiado lentas. Si enseñas funcionalidades premium, enseñar también como se compran, enseñar el botón de pagar.	-
Grupo 8 - Nutribaby	- Centrarse en cómo conseguir usuarios. - Storyboard: No hablar de forma indirecta. Que no aparezca la aplicación de manera mágica (posible estrategia para evitar esto es que la aplicación se dé por descargada, como que no se entiende que alguien no la tenga). - Inversores: Cuando hablas de cifras, debemos poner con esta inversión consigues este porcentaje de beneficio en tanto tiempo. Los números son lo que hace que alguien se decida por invertir o no. - Tener en cuenta el Life Time Value (LTV). - Ingresos: Es muy difícil comparar con 3 diapositivas distintas, poner uno encima de otro. Poner . de miles en los números. - Que las fotos del equipo sean homogéneas. - Rendimiento individual: No usar porcentajes para enseñar esto, porque no se ve quién es cada uno ni quién ha trabajado bien/mal. - Testing 0% cobertura ??? - Informe tan completo en el que han usado las métricas. Da seguridad y objetividad a la hora de poner las cosas encima de la mesa. - No hacer referencia a archivos concretos, para la gente no tiene sentido. - Tener cuidado con las faltas de ortografía: papa /= papá. - Ejemplo de la IA: Ser más concretos. Decir a qué IA se le ha pedido lo que sea. - Ausencia de inicio efectivo.	-
Grupo 9 - Caronte	- Presenta bien. - Bien aclarado por ejemplo las unidades de los números sin dar por hecho que la gente sabe lo que son. - Killer opener: Apoyar la técnica que se use con algo visual. - En el storyboard el mensaje se tiene que ver claramente, pensar que esto se puede convertir en anuncio. - Muy buena gráfica de monetización: mucha información en poco espacio, buen uso de los colores. No usar "pérdidas", usar "gastos". - Tener en cuenta la posible influencia en los costes de cosas como el GDPR. - Lecciones aprendidas: Medir el grado en el que ha servido la solución usada para un problema. - Muchas horas invertidas, si es necesario acortar el alcance. - Uso inteligente de la tecnología. - Buena gráfica de tareas realizadas: product backlog. - DEMO: Mejor en vídeo. Poner en texto en una esquina qué caso de uso se está probando en el video. Que se vea el icono del usuario que está logueado. No mezclar demo con, por ejemplo, feedback de usuarios piloto si esto todavía no se ha mencionado en la presentación. - Buen uso de Codacy. Sería bueno poner en el futuro una gráfica para ver la evolución del código. - Se debe explicar la manera de medir el rendimiento individual del equipo (con diapositiva). - Si se hace una pregunta importante por el grupo del equipo y no responde todo el mundo, es un problema grave de comunicación.	-
Grupo 10 - Go4Surprise	- Explica quiénes son sin decir lo que hacen. Se comparan con aplicaciones de venta de entradas cuando no es directamente lo que hacen ellos. Ellos ofrecen experiencias y no lo mencionan. - Desde el killer opener plantear ya el problema, la situación. No hacer preguntas al público porque el que no se sienta identificado no echa cuenta desde el principio. - Desde el punto de vista de una presentación de negocio, poner la fórmula usada para calcular la estimación de ingresos TAL CUAL, MAL. Explicar de forma más intuitiva, los factores que influyen. - Impacto legal -> Licencia del software -> Visualizar el código fuente ???? Esto surge por el problema de tener el código en un repositorio abierto. - Buenas viñetas en la storyboard, pero tener cuidado porque estas después se tienen que convertir en anuncio. Evitar la "magia" de que de repente aparezca tu aplicación, darle un poco de contexto, de introducción. Que no sea "tengo este problema" y de repente "pues esta aplicación es tu solución". - DEMO: El registro en la aplicación demasiado rápido. Lo ideal es que el vídeo se centre en los casos de uso. - Casos de uso CORE: tenerlos claros y se pueden recortar los que no sean tan necesarios. - Compromiso bueno pero problemas de comunicación ?? - Medir las soluciones, plantear el objetivo al que quieres llegar con ella, seguir la evolución. - Fallos en la plataforma -> Entrar más en detalle, el porqué de estos fallos. - Fondo oscuro -> Letras más claras.	-
Grupo 11 - Pawtel	- Problema: Ha faltado "terminar" el killer opener presentando lo que hacemos. En vez de decir "ojalá hubiese una aplicación..." decir "pues mira, he encontrado esta aplicación..." (lo puede decir por ejemplo el que esté en el PC). - En el elevator pitch, demasiados pasos que hacen fricción. No decir me registro, me logueo,... Ir directo al grano. - Si hablas rápido usarlo como recurso, no como constante. - Aunque el nombre de "María Jesús" está bien, debemos elegir una palabra para repetir muchas veces, que se quede en la cabeza de la gente, por ejemplo, mascota. (Esta quita la parte afectiva así que mejor buscar otra, pero es un ejemplo). - RGPD: Hablar más de los datos. Cuáles son los que se necesitan, se van a guardar? (Si los datos no eliminan ninguna fricción mejor no guardarlos). - DEMO: Optimizarla y mejorar visibilidad. - Costes: El desarrollo NO es un gasto operativo. Es CAPEX. - Calidad de código: Configurar el entorno con un estándar para compartir el estilo de código, que parezca que todo lo ha hecho el mismo.	- Feedback de los compañeros: Muy buena presentación de Javi y destacan las métricas para medir el rendimiento individual y los storyboard.
General	- OBLIGATORIO -> Customer agreements: Garantizar que tenemos la evidencia de que un usuario se lo ha leído y está efectivamente de acuerdo. Fijarnos en PayPal. - Añadir changelog: Que hay nuevo, que es lo que ha cambiado del sprint 1 al 2. Se pueden utilizar conventional commits, hay extensiones de VSC que te permiten seguir los mensajes de los commits y crear el changelog automáticamente. Mejor no hacerlo manual. También se puede con GitHub. - Debemos llegar a un acuerdo con los usuarios piloto (además del plan de gestión) donde se acuerdan los términos. Me comprometo...	-

Para hacer pero no necesariamente para la presentación

Para la presentación

Estructura principal

15 min (siempre ya) A lo que hicimos la semana pasada, añadimos: Storyboard: Obligatorio tener uno para cada usuario/cliente/inversor. Términos de servicio: Evitar las cláusulas abusivas. Estos son: Que ofrecemos en nuestro proyecto? Que servicios? No podemos obligar por ejemplo a que el usuario de una información que no está obligado a dar. Definir pricing (lo más claro posible), SLA (Service-level agreement) (comprometido también con las APIs externas, que pasa si falla alguna?), licencias, GDPR. En la presentación poner un resumen solo, no un textazo explicando todo. Análisis de costes: Estandarizar el tiempo -> 2 AÑOS, empezando al principio del cuatrimestre, y distinguiendo CAPEX/OPEX. Retrospectiva sprint 2: Es la parte más importante de la presentación. Rendimiento: Mostrar gráfico de rendimiento y de esfuerzo. Se puede complementar con otras cosas, pero eso es obligatorio. Que muestre a todos los miembros del equipo. Hacerla como sistema de coordenadas, cuatro zonas, eje x= esfuerzo, eje y= rendimiento y un punto por miembro del equipo (linea 45º divide en 2). Poner también un punto con la media y marcar con una línea las 10 horas. A partir de ahora se van a tener en cuenta las píldoras teóricas en las presentaciones, echarles un vistazo. Planificación sprint 3: Se debe incluir pago real con cuenta sandbox, aspectos de seguridad (ej: validar que la cuenta de correo con la que alguien se registre exista de verdad, validar la tarjeta de crédito... (todo lo que sea validable). si usamos una API externa son ellos los que se encargan de esto) Uso IA: Analizar y contar como nos está ayudando el uso de la IA. Lecciones aprendidas del uso de la IA. Destacar también las "alucinaciones" que tenga.

Otros

Adicional

---

Semana 8

---

Fecha: 29/03/2025

Desarrollo

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYouWorld	100€ al mes cada empresa??? Los storyboard tienen que ser independientes entre ellos. Análisis de costes es muy difícil de leer. Con una tabla es mucho más simple. Hay muchas diapositivas en las que se pierde el número de referencia. Métricas de productividad → Explicar por qué hay algunos muy arriba?, ¿qué pasa con los que están más abajo? Tabla org. sprint2: justificar por qué se ha hecho cada 2 días. Calidad del código: No contar solo las métricas, analizar cómo se está trabajando, cuáles son las buenas/malas prácticas,... Planificación y objetivos: Lo que hay que poner es el retraso acumulado que lleva el proyecto, no el % de horas utilizadas.	-
Grupo 8 - Infantem	Bien en general, muy buen killer opener y bien hilado con la demo. Buen storyboard de cliente. Si pones variables explicar qué son. Mucho texto, usar más las diapositivas como apoyo que como guía. Buscar metáforas visuales. Buena prioridad de usuarios piloto. Han quedado claras las funcionalidades que tenía. Intentar ir cambiando el tono durante la presentación. Métricas de código: la calidad del código general no es tan relevante, sino centrarse más en las cosas a mejorar y la evolución. Costes: La diapositiva no es solo de costes, sino de costes e ingresos.	-
Grupo 9 - Caronte	Bien en general. Killer opener: Muy bien pero viendo el nivel de los storyboard se podría hacer mucho más efectivo/original. Orden de presentación: Mejor que sea Killer opener → Storyboard → Competidores → Demo, para poder hilarlo. Remarcar lo que te diferencia de los competidores. Customer agreement: Usar aplicaciones como Kloudete, en caso de usarlo mencionarlo. Negativo: La DEMO no se ve, recomendación: donde esté el cursor que se haga zoom. Muy buena matriz de dispersión, buena explicación con uso del zoom. Buena parte calidad del código, pero poner la calidad inicial y final las dos en la misma diapositiva, cabe de sobra y así se ve mejor la evolución. Mostrar qué criterios se están usando para priorizar el feedback de los usuarios piloto.	-
Grupo 10 - Go4Surprise	Bien presentado e hilado. Ha contado mucho sin tener que correr. Inicio muy efectivo. Tener cuidado con el uso del lenguaje coloquial. Para el killer opener sirve, en el resto de la presentación no tanto. No estar presentando mirando todo el rato a los mismos. No usar la dinámica pregunta-respuesta. Buena idea la mascota. El CAPEX es una inversión que se amortiza poco a poco. Pagar salarios no significa que la empresa esté en pérdidas. Hablar más de inversiones que de gastos. DEMO: Bien, se ve bien, pero hilar con el ejemplo del killer opener. Parte de soluciones hacer un resumen. En la gráfica del rendimiento del equipo en vez de poner la foto de cada uno poner un punto, y se pueden poner los puntos de semanas anteriores y trazar líneas uniéndolos para ver la tendencia de cada uno y la evolución.	-
Grupo 11 - Pawtel	Javi: Buena presentación pero que intente hablar un poco más despacio, que dé tiempo a la gente a procesar la información. Poner menos diapositivas, decir mucho con poco. Muy buen killer opener, bien hilado con el pingüino. Hay que hilarlo también con la demo, que hace que sea todo mucho más coherente. Muy buen uso de los colores en los storyboard. Bien centrado el mensaje en la palabra 'mascota'. Análisis de competidores: Ser repetitivo con que somos un 'COMPARADOR de hoteles para mascotas', que es lo que nos diferencia del resto. Atraer a los inversores con cifras, no con palabras. Mala diapositiva de la evolución de costes (I). Mala diapositiva de rendimiento. Eje X desde 0, Eje Y es número de tareas, y después ampliar la zona donde estemos todos. Buena diapositiva de barras de cambio en el rendimiento. No se entiende bien la diapositiva 28, de evolución en el rendimiento del equipo. Calidad del código: Hay que poner cuál es la evolución. Retrospectiva: Buena idea la figura del mediador. Incidencias y resolución de problemas (III): poner las cosas para que se lean de arriba a abajo y de izquierda a derecha. DEMO: Poner rangos cuando sean rangos. No poner de 20 a 20. Y dejar claro que el precio que te sale es el total de la reserva, no cuánto vale la noche. Igualmente ser realistas con los precios, en la demo sale 932€.	Feedback de los compañeros: Muy buena presentación de Javi y destacan las métricas para medir el rendimiento individual y los storyboard.
General	Recomendación del profesor: Buscar un slogan además de la mascota.	-

Para hacer pero no necesariamente para la presentación

Para la presentación

Estructura principal

15 min (siempre ya) A lo que hicimos la semana pasada, añadimos:

• Uno de los storyboard tiene que ser ahora un anuncio de verdad, en vídeo grabado.
• Contar que ha pasado en la primera mitad del sprint 3.
• De cara al WPL, presentar un plan de pruebas.
• Presentar mejoras en la UI/UX.
• DEMO: Destacar aquello que tenga relación con cuestiones regulatorias (datos, privacidad...).
• Presentar la evolución de las soluciones a problemas. Ver su efectividad con métricas apoyadas en datos.
• Calidad de código: Decir a que queremos llegar una vez finalizado el sprint, a qué aspiramos (puntajes de calidad,...).
• Plan de usuarios piloto: Darle prioridad al feedback usando un ranking. Explicar como funciona este.
• Tener planes B en caso de que alguna API externa que usemos falle (ej: Stripe, hay que ver cuantas peticiones permite).
• Planificación preliminar para la siguiente fase, centrada en marketing (como lo vamos a hacer en rrss,...).

Otros

Adicional

Semana 9

Fecha: 04/04/2025

Desarrollo

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 8 - Infantem	Hacer anuncios que no dependan del storyboard. Buen intento de anuncio de inversores. Faltan en la demo fotos reales de las recetas. No se han destacado en la demo las mejoras de la interfaz de usuario hechas a partir del feedback de los usuarios piloto. Problemas casi todos de implementación. Bien hecho la priorización de los problemas de los usuarios piloto. Bien el manual de imagen corporativa.	-
Grupo 9 - Caronte	Video bien en general, un poco largo y las pantallas con texto se pueden poner en una sola pantalla. Storyboard de inversores se identifica bien el objetivo y nicho de mercado, pero le faltan las opciones de inversión. Color de CAPEX no se corresponde con el color corporativo y debe corresponderse. En el gráfico de horas invertidas, ver el diferencial con respecto a una semana normal, ver la media de cada miembro y encima las horas de la semana que se evalúa en concreto. Prueba de interfaz con selenium puede ser interesante para los test del frontend. En feedback de usuarios piloto, poner en la pirámide un cuarto nivel de cosas a ignorar junto con la razón de por qué se ignora.	-
Grupo 10 - Go4Surprise	Muy bien el slogan en el inicio efectivo y la mascota también, punto muy positivo. Anuncio un poco largo, en el video no se veía bien el móvil donde se usaba la app. No se ha puesto en las estimaciones optimistas, pesimistas y realistas el número de usuarios que utilizan Go4Surprise. En los problemas y soluciones (que son 2 diapositivas distintas), no hay correlación de todos los problemas con las soluciones presentadas en la siguiente diapositiva. En la gráfica de rendimiento del equipo, poner una línea entre los puntos correspondientes a una semana y la siguiente, la media y la semana actual.	-
Grupo 11 - Pawtel	Inicio efectivo mucho mejor, elegir mejor las palabras. No le gustan las palabras en inglés y técnicas cuando ya hay alguna en español, como es “matchmaking”. No decir “esto es muy fácil” o cosas del estilo para que el que no lo entienda no se sienta tonto. En vez de decir esto machacar las partes que deben entenderse. Muy bien hilado el inicio efectivo con el anuncio y la demo y el final. El anuncio muy profesional y muy muy bien. El storyboard de usuarios también. Ollie pisando y dejando la huella y que aparezca el logotipo (Tip para mejorar aún más). Poner a los números en las tablas k, 10k en vez de 10000. Es anticlimático poner lo que no debe hacerse en el impacto legal del proyecto. Gráfica del rendimiento del sprint 3: Si casi todo el mundo está en el 10 hay algo que no funciona. Los números de los lados no se ven. No tiene sentido que en 4 o 6 horas se haga lo mismo que en 20 horas. Demo_04_04.mp4, mejor sustituirlo por un emoticono clickable o algo pero cambiar eso. Priorización del feedback de usuarios pilotos muy muy bien. Problemas técnicos sí es nuestra prioridad pero no debería ser parte de los usuarios piloto encontrar estos errores. UX es opinión de los usuarios piloto sobre lo que ya existe y gustos son cosas que les gustaría a los usuarios piloto que no están.	-
Grupo 7 - MapYourWorld	Inicio efectivo muy bueno y bien hilado con el anuncio. No decir 5’50 por el premium y después no contar las funcionalidades premium. Poner límites a los inversores. Ellos ofrecen un 5% y si llegan 11 inversores ya tienen un 55% de la empresa. También con las compensaciones. En la gráfica de proyección financiera los ejes pesan distinto y chirría mucho. En las métricas de productividad usar los segmentos con un gradiente de color para que se vea mejor la direccionalidad. No usar flechas. Muy bien poner la evolución de calidad del código.	-
General	Recomendación del profesor: Buscar un slogan además de la mascota. Otra recomendación: Si alguien no está trabajando como debería: - Empatía en el grupo - Cambiar el tipo de tareas a los que menos trabajan para que puedan resarcirse - Tener supervisores que serían los que más han trabajado y que estén pendientes de los que menos han trabajado y tengan una relación más estrecha.	-

General: -Recomendación del profesor: Buscar un slogan además de la mascota. -Otra recomendacion: Si alguien no está trabajando como debería:

• Empatía en el grupo
• Cambiar el tipo de tareas a los que menos trabajan para que puedan resarcirse
• Tener supervisores que serían los que más han trabajado y que estén pendientes de los que menos han trabajado y tengan una relación más estrecha.

Otros

Van a permitir con una tarea extra subir medio punto individual y aparte un documento de lecciones aprendidas de sprint1 y/o sprint2 para recuperar nota del no apto (si tenemos apto no hay que hacerlo).

Para la semana que viene:

• El anuncio en vídeo basado en el segundo storyboard.
• Desaparece Customer Agreement
• Gestión de tracción inicial en el mercado (como ganamos clientes)
• Cómo repartir responsabilidades de marketing en el equipo.
• Tco. Actualizar costes con el estudio preliminar de marketing
• Mantener estructura del equipo y añadir los nuevos roles de marketing
• Demo como siempre
• Retrospectiva como siempre

Adicional

Semana 10

Desarrollo

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYourWorld	- En la semana 30 bajan los gastos y después vuelven a subir, incoherencia, tener claro por qué pasan cosas como esta. - No ha habido killer opener como tal. - Audio de los vídeos mal, cuando se ponga el proyector tiene que estar mute. - DEMO demasiado acelerada y la música de fondo despistaba más que ayudaba. - No puedes decir "por eso a este no lo consideramos un competidor directo" y que aparezca en la tabla de competidores. - Anuncio de inversores: Los paquetes de inversión son demasiado pretenciosos, mejor tener muchos paquetes que valgan menos a un gran inversor. - PPL: Buenos tipos de contenidos en RRSS según usuarios, campañas pre-durante-post lanzamiento. - Hay que ser más específico en una planificación de lanzamiento (qué se va a hacer cada día, cuándo se van a hacer las publicaciones, etc.). - Medir efectividad de publicaciones y reflejar NUESTRA REACCIÓN a ello. - Ver cuánto se espera ganar con anuncios y qué se va a hacer si no se llega a esa cifra. - Buena diapositiva de branding (logo, paleta de colores, tipografía, logos alternativos...), pero falta indicar el peso de cada elemento.	-
Grupo 8 - Infantem	- Falta hilo argumental. - Buen trabajo en general. - Gran mejora del presentador. - DEMO un poco escueta para todas las funcionalidades que tiene la aplicación y que la hacen distinta de los competidores. - Falta mucha información en la diapositiva de costes-ingresos-beneficios (hacerla homogénea en escala y visible). - Vídeo para inversores demasiado escueto. - Bien pensado colaborar con influencers. - Bien pensado el filtro de TikTok, pero que salga un bebé. - Planificación: Han usado a la mascota para marcar los días pero no se explica qué significa que salga (¿hay publicación? ¿cuántas? ¿en todas las plataformas?).	-
Grupo 9 - Caronte	- Muy buena presentación. - El mensaje inicial: falla la diapositiva, demasiadas cosas; el vídeo explica mejor. Se puede cambiar el orden y usar el vídeo también para la presentación. - Buena DEMO. - Moral del equipo y horas invertidas sobra. - Falta apoyo visual en la monetización. - El vídeo de inversores no se entiende. - Protopersonas: Estado civil /= situación laboral. - Campaña: igual que el grupo anterior.	-
Grupo 10 - Go4Surprise	- No hacer retrospectiva del desarrollo. - Para el WPL poner en el TCO la estimación esperada/realista. - Comentar modelo de negocio. - No poner "1K = 1000 euros" en la gráfica del TCO. - No publicitarse en LinkedIn si buscamos usuarios finales (solo para buscar empresas como mucho). - Es importante conocer bien el nicho al que apelamos para utilizar su red social óptima de la mejor manera.	-
Grupo 11 - Pawtel	- Si el público objetivo son perros, debemos ir a buscar a ese nicho principalmente. - IMPORTANTE: no repetir el fallo de los vídeos; tener backup. - Enseñar los vídeos en modo presentación (no mostrar todas las diapositivas detrás). - Anuncio Coco: historia no muy realista; falta apoyo visual. Se sugiere usar el perro Curro (de la primitiva) como ejemplo. - Usar demo para explicar cómo Coco usa Pawtel (usar una patita en vez del cursor). - Cuidado con el audio de la demo, estaba demasiado alto. - Considerar puenteo de reservas tradicionales: estrategia de puntos tipo booking (aunque no esté implementado). - Cuidado con el desfase audio-vídeo, ser muy perfeccionista. - El vídeo de inversores está bien. - Protopersonas: diferenciar problemas de soluciones. ¿Qué problema tienen? - Gráficas de búsquedas: fechas no se ven bien. Resaltar la estacionalidad y correlaciones observadas. Indicar a qué nivel es la gráfica (España). - Nombrar las IAs usadas en marketing. - Carteles: van a pedir minicartel para poner en la escuela (ver proporciones en la web de la escuela).	-

Para hacer pero no necesariamente para la presentación

Para la presentación

Estructura principal

Para la semana pasada fue así:

• La presentación que teníamos hibrida hecha hasta ahora se divide:
  • Presentación 1: WPL (10min): ESTE ES EL ORDEN QUE HAY QUE SEGUIR
    • De que va el proyecto? Killer opener + anuncio orientado a clientes (Video 1min max) (1min EL APARTADO)
    • Que hace exactamente? Mas detallado, con DEMO del proyecto basada en una historia realista, normalmente optimista (nada de recuperar correos,... eliminar fricciones). Consistente con lo visto anteriormente.
    • Hay competencia? Lo de siempre.
    • Quien hay detras? EL equipo. La estructura será un poco menos relevante.
    • Podria ser rentable? Puntos principales del modelo de negocio. Fuentes de ingresos, costes, oportunidades de inversión (donde ponemos el video para inversores (Duración máxima del vídeo 1 minuto)).
    • Donde puedo ver mas informacion? Transparencia final con link a landing page, qr, producto.
  • P.2: Resto (PPL, marketing) (5min)
    • Modelo de segmentación: A que segmentos vamos a orientar nuestro producto (Habrá que caracterizar a la audiencia), poner un par de protopersonas.
    • De qué forma vamos a optimizar nuestra presencia en los motores de búsqueda (palabras clave). Si vamos a tener presencia en rrss que van por población, tirar de las protopersonas.
    • Campaña de lanzamiento, acciones antes del wpl. Crear nuestras rrss y hacer contenido, que debe seguir un plan. Definir acciones que permitan ganar usuarios, clientes, visibilidad. Buscar partnerships, influencers,...
    • Objetivos de la gestión de la comunidad: planificar cuando se hacen publicaciones, con que objetivo,...
    • Costes de marketing: Detalles.
    • Anuncios dirigidos: Videos, planes,... Actualizar la landing page con este contenido. Se pueden poner videos que no enseñemos en el WPL si no caben ahí.
    • Se puede añadir a esta el uso de la IA
• Sobre esto:
  • Aplicando el feedback, se debe ver evolución en la presentación.
  • Pasar más de plan de marketing a plan de ejecución.
  • Será importante aprovechar el ensayo del WPL (tema sonido de videos, voz al hablar, etc).
  • La semana que viene es retrospectiva personal de cada integrante del equipo, vendremos un rato solo.

Otros

Adicional

• Hay una plataforma para sacar al mercado startups.
• Hay un concurso de la US para presentar startups.

Semana 11

Desarrollo

Feedback de las presentaciones

Grupo	Feedback recibido	Observaciones adicionales
Grupo 7 - MapYourWorld	- Buen killer opener, pero tener cuidado en el WPL que es en el salón de actos (sonido, hacer alguna referencia a ello). - Buen video de clientes pero la última frase tiene mucho eco. - DEMO: Bien, pero debe tener una historia completa para toda la presentación, sin dependencias entre aplicaciones. - Si dices que te diferencia crear una cuenta en 30s, entonces debes comparar con los competidores. - Inferir que los paquetes de aparición son para empresas, y explicarlos con más calma. - No se puede hacer una proyección de beneficios sin explicar fuentes de ingreso. - Paquetes de inversión: Separar precio de la acción y múltiplo mínimo. - Hablar de rentabilidad de los paquetes de inversión. - Usar keywords que la gente realmente busque para SEO. - Bien: Seguimiento y KPIs.	- Feedback positivo: Killer opener, que nos diferencia, video inversores, diferenciación entre RRSS, brandboard.
Grupo 8 - Infantem	- Buen anuncio de clientes. - Si la DEMO no tiene sonido hay que acompañarla. - Fuentes de ingresos: El tiempo es clave para ver la evolución del modelo. 13% freemium al principio es demasiado. - Mala diapositiva de costes, ingresos y beneficios. - Protopersonas: Poner más información sobre el bebé. - Marketing: Aterrizarlo en casos concretos, usar datos. - Estadísticas: Usar gráficas aunque sean pocos días. - La campaña de influencers debería tener presupuesto. - Decir en qué se va a gastar el dinero solicitado a inversores y cómo influye. - Buena idea los carteles.	- Feedback positivo: Killer opener, video clientes, diseño diapositivas, carteles, sorteos como campaña de marketing, uso de IA muy completo.
Grupo 9 - Caronte	- Muy bien, la mejor a nivel de presentación. - Volumen de los videos demasiado alto y compitiendo con la música. - Video de inversores: Eliminar la parodia, hacerlo más neutro. No tiene por qué ser un diálogo.	- Feedback positivo: Video clientes, DEMO, usuarios piloto, concurso de anuncios, camisetas y acreditaciones.
Grupo 10 - Go4Surprise	- Muy bien en general. - ¿Por qué dos videos de clientes? Explicar y situar uno en marketing/publicidad. Cuidar la iluminación y el entorno. - Cambiar cómo se presentan los paquetes en el video de inversores. - Keywords demasiado genéricas.	- Feedback positivo: DEMO con interacción con el presentador, rentabilidad, video de inversores, Fever Futura Tech Prize, uso de métricas Metricool para RRSS.
Grupo 11 - Pawtel	- No detallar tanto la organización de los grupos. Usar términos generales como "equipo de desarrollo", "coordinadores"... - Costes: Aclarar si se han añadido los Pawpoints. Si no están, incluirlos. - Costes: Evitar usar CAPEX y OPEX, términos demasiado técnicos. Usar otros más comprensibles tanto en diapositiva como en presentación oral. - En los anuncios, quitar los números de página si se enseñan diapositivas dentro. - Posicionamiento digital: Buena diapositiva, pero explicarla de forma más sencilla. Puede dividirse en dos. - Buen análisis de redes sociales. - Los números de las diapositivas del PPL están todos mal.	- Feedback positivo: Muy buen recurso el del co-branding en el killer opener. - El audio de los videos: comprobarlo antes del WPL. Tener plan B.

Para hacer pero no necesariamente para la presentación

Para la presentación

Estructura principal

Para la semana que viene: El grupo de manera individual

• Pequeña presentación de máximo 5 minutos de los problemas que ha habido, soluciones aplicadas, nuestra visión, manera de evaluar a los miembros del equipo, notas, cosas a destacar,... Sobre todo el proyecto (no solo la última semana). Nos van a hacer preguntas sobre que ha ido bien, que ha ido mal, como se han solucionado los problemas que han ido surgiendo,...
• Preparar un slide anunciando nuestro proyecto que se presentará en las pantallas de la etsii. Nos darán una plantilla para saber el formato, pero después no tenemos por qué seguirla.
• WPL:
  • Será el dia 23 de mayo de 12:30 a 17:30. No tenemos que ir al turno de mañana.
  • El ensayo es el Jueves 22 de mayo 13:30-16:30 en el salón de actos.
  • Presentación 10 minutos. Lo que tenemos ya, añadiendo la parte de marketing.
  • Nos darán unos premios según el mejor presentador, mejor DEMO, mejor killer opener,...
  • Evento publico, se puede invitar a gente de fuera.

Otros

Adicional

• Encuesta anónima para hacer cualquier comentario sobre la asignatura: bit.ly/ispp-acp